The present application generally relates to field programmable devices and, more particularly, to deploy and utilize a software library and a corresponding field programmable device binary.
Special purpose processing units are gaining popularity due to their high performance. In some situations, hardware manufacturers have begun adding field-programmable device-based special purpose processing units to computing systems to improve performance and cost to run a special workload. A field-programmable device (FPD) such as a field programmable gate array (FPGA), a programmable read-only memory (PROM), or a programmable logic device (PLD) provides more flexibility compared to traditional integrated circuit manufacturing by allowing updating of functionality after shipping the computing system (i.e., while the computing system is in the field). The update of functionality of an FPD is currently limited to firmware upgrades, service related tasks, or a human decision to re-purpose an FPD.
One issue that software vendors face when enabling their software libraries to exploit FPDs is how to provide application program interfaces (APIs) that can take advantage of an FPD when one is available but also provide compatible functionality when an FPD is not available. It is important for software vendors to provide this type of compatibility to allow their software to be used by both customers who have a computing system with FPDs and customers that do not have FPDs. An example of this approach is provided by IBM's z/OS operating system. z/OS supports the IBM z Systems Data Compression (zEDC) which is an FPD that provides acceleration for data compression. Provided with z/OS is a modified version of the zlib data compress software library. The modified zlib may use a zFDC to accelerate data compression requests. The modified zlib may use a zEDC in certain cases except: 1) when no zEDC is available in the computer system, 2) when the zlib function requested is not supported by the zEDC, or 3) when the request is too small to be efficiently processed by the zEDC. These criteria to use the zEDC are static in nature and there is no attempt to make dynamic runtime trade-off decisions on whether it is appropriate to use a zEDC for a given API call.